(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
Inicmaiional Bureau 

(43) International Publication Date 
7 March 2002 (07.03.2002) 




PCT 



lllilllilllllllllllllllliill^ 

(10) International Publication Number 

wo 02/19585 Al 



(51) International Patent Classification^: H04J3/16 

(21) International Application Number: IKTI AJSO 1/24925 

(22) International Filing Date: 7Augusi2()0] (07.08.2001) 

(25) Filing Language: English 

(26) Publication Language: Hnglish 



(30) Priority Data: 
09/652,750 



3 1 August 2000 (3 1 .08.2000) US 



(71) Applicant: VERIZON COMMUNICATIONS INC. 

fUS/US]; 1320 North Court House Road, Arlington, VA 
22201 (US). 

(72) Inventors: VOIT, Eric, A.; 5611 Oakmonl Avenue, 
Belhesda, MD 20817 (US). BAUM, Robert, T.; 429 
Girard Su-eet #304, Gaithersburg, MD 20877 (US). 

(74) Agent: SUCHYTA, Leonard, C; c/o Andersen, Chris- 
tian, R., 600 Hidden Ridge Drive, Mailcode HQE03H01, 
Irving, TX 75038 (US). 



(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ, DE, DK, DM, DZ, EC, EE, ES, R, GB, GD, GE, GH, 
GM, HR, IflJ, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT,IlU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, PL, Pi; RO, RU, SD, SE, SG, SI, SK, 
SL, TJ, TM, TR, T\\ TZ, UA, UG, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO palcnl (GH. GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM ), European 
patent (AT, BE, CH, CY, DE, DK, ES, Fl, FR, GB, GR, IE, 
IT, LU, MC, Nl., PT, SE, TR), OAPl patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, 
TG). 

Published: 

— with internalional search report 

— before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



(54) Title: METHODS, APPARATUS AND DATA STRUCTURES FOR SEGMENTING CUSTOMERS USING AT LEAST A 
PORTION OF A LAYER 2 ADDRESS HEADER OR BITS IN THE PLACE OF LAYER 2 ADDRESS HEADER 



\352j - 







^^^^^^^^^^^^^ 
SOURCE AOORESS 146 BTTS^^P 


eo2.io 

VLANE 
TP© 




LfeMGTM, 
ETC. 


PROTOCOL 


PORT 
3232 


L3 SOURCE AOaRES 




U DESTINATION AOORESS 


TVPEOf 




OAtA 




in 

00 

in 

ON 

r5 

o 



(57) Abstract: Limiting or controlling access to various services thereby performing a firewall function. An access router may 
permit or deny a packet based on at least a portion of a unique bit string (or context information) which replaced layer 2 header 
information (e.g., the layer 2 (e.g., MAC) address). Further, a particular quality of service may be indicated by at least a part of the 
unique bit string (or context information). The service provided to a group of customers, that group of customers being defined by 
at least a portion of the unique bit string (context information), may be monitored. Multicast groups may be supported by checking, 
at least a part of the unique bit string (or context information) to determined whether or not a customer associated with that port is 
permitted to join the multicast group. 
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METHODS, APPARATUS AND DATA STRUCTTJRES FOR SEGMENTING 
CUSTOMERS USING ATLEASTAPORTION OF ALAYER 2 ADDRESS 
HEADER OR BITS IN THE PLACE OF A LAYER 2 ADDRESS HEADER 

5 

§1.1 TECHNICAL FIELD 

The present invention concerns methods, apparatus and data 
structures for aggregating traffic, which may originate from various media 

10 transport types, for presentation to a router, such as an access router of a 

network. Further, the traffic aggregation performed by the present invention 
may be done such that customers can be identified and such that customer device 
addressing mformation is available. Moreover, the traffic aggregation perfonned 

by the present invention may be done such that the service provided to a group of 
15 customers maybe monitored; multicast groups are secure; and the access router 
can control access to services, facilitate virtual private networks, and facilitate the 
provision of different quality of service and/or class of service levels. 



20 



25 



30 



§ 1.2 BACKGROUND 



The description of art m this section is not, and should not be 
interpreted to be, an admission that such art is prior art to the present invention. 

§1.2.1 COMMUNICATIONS PROTOCOL STACK 



Although networking software and network reference models 
known to those skilled in the art, they are introduce here for the reader'; 
convenience. 



are 

s 



To reduce their complexity, networks may be organized as a series 
of layers, each one bmlt upon the one below it as shown in Figure 1. Each layer 
functions to offer certain services to the higher layer, thereby shielding those 
higher layersfrom the details of howthe offered services are actuafly 
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implemented. The entities comprising the corresponding layers on different 
machines are called "peers". Such peers use rules and conventions, also referred 
to as the layer n protocol, to conmiunicate with each other as depicted by the 
dashed lines in Figure i. Actually, no data are directly transferred from layer n on 
5 one machine to layer n on another machine. Rather, in the machine transmitting 
the data, each layer passes data and control information to the layer immediately 
below it, until the lowest layer Gayer i) is reached. Below layer i, is a physical 
mediimi no through which actual commimications take place. At the machine 
receiving the data, each layer passes data and control information to the layer 
lo immediately above it imtil the highest layer is reached. Thus, referring to Figure 
1, actual communications take place via the solid lines and the physical medixmi 
no, while virtvial peer-to-peer conMnimications occur via the dashed lines. 

StiU referring to Figure i, interfaces are arranged between adjacent 
15 layers. Each of these interfaces defines primitive operations and services that the 
lower layer off ers to the upper layer. 

The set of layers and protocols may be referred to as a "network 
architecture". A list of protocols used by a system, one protocol per layer, may be 
20 referred to as a "protocol stack" or "protocol suite". 

§ 1.2.2 NETWORK ARCHITECTURE REFERENCE MODELS 

Figure 2 illustrates a comparison of the Open Systems 
25 Interconnection (or "OSI") reference model 210 for network architectures and the 
transfer control protocol/Internet protocol (or "TCP/IP") reference model 220 
for network architectures. Although those skilled in the art will be familiar with 
both reference models, each is introduced below for the reader's convenience. 

30 § 1.2.2.1 THE OSI REFERENCE MODEL 

As shown in Figure 2, the OSI reference model 210 has seven (7) 
distinct layers; namely, (i) a physical layer 211, (ii) a data link layer 212, (iii) a 
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network layer 213, (iv) a transport layer 214, (v) a session layer 215, (vi) a 
presentation layer 216, and (vii) an application layer 217. Each layer is briefly 
introduced below. 

The physical layer 211 deals with transmitting raw bits over a 
communications channel. Thus, the phydcal layer is typically concerned with 
mechanical, electrical, optical, and procedural interfaces, is well as the physical 
transmission medium (e.g., twisted copper pair, co-axial cable, optical fiber, etc) 
that lies below the physical layer. 

The data link layer 212 functions to transform a raw 
communications faciUty mto a line that appearsfree ftom undetected 

transmission errors to the network layer 213. The data link layer 212 does this by 

having the sending host segment its data mto "data frames", transmitting these 
frames to the receiving host and processing ''acknowledgement fi^mes" sent 
back from the receiver. 



The network layer 213 functions to confrol the operation of a 
subnetwork between the hosts and confrols the routing of packets between the 
20 hosts. 

The transport layer 214 functions to accept data from the session 
layer 215 and segment this data mto smaller units, if necessary, for use by the 

networklayer2i3. transport layer 214 also determines a type of service (eg 
25 error-free, point-to-point) to provide to the session layer 215. Further the 

transport layer 214 controls the flow of data between hosts. The fransport layer 
214 is a true "end-to-end" layer, from source host to destination host, since a 
program on the source machine converses with a similar program on the 
destmation machine, usmg message headers and confrol messages. 



30 



The session layer 215 Wtions to allow different machines to 
establish sessions between them. The session layer 215 may manage dialog 
control and maintain synchronization. 
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The presentation layer 215 concerns the syntax and semantics of 
information transmitted. 

5 The application layer 216 may function to define network virtual 

terminals that editors and other programs can use, and to transfer files. 

i 

§1.2.2.2 THE TCP/IP MODEL 

10 In recent decades, and in the past five (5) to ten (10) years in 

particular, computers have become interconnected by networks by an ever 
increasing extent; initially, via local area networks (or "LANs'O, and more 
recently via LANs, wide area networks (or WANs) and the Internet. In 1969, the 
Advanced Research Projects Agency (ARPA) of the U.S. Department of Defense 

15 (DoD) deployed ARPANET as a way to explore packet-switching technology and 
protocols that could be used for cooperative, distributed, computing. Early on, 
ARPANET was used by the TELNET application that permitted a single terminal 
to work with different types of computers, and by the file transfer protocol (or 
"FTP'') which permitted different types of computers to transfer files from one 

20 another. In the early 1970s', electronic mail became the most popular application 
which used ARPANET. 

This packet switching technology was so successfiil, that the ARPA 
applied it to tactical radio conmiimications (Packet Radio) and to satellite 

25 communications (SATNET). However, since these networks operated in veiy 
different commuaiications environments, certain parameters, such as maximum 
packet size for example, were different in each case. Thus, methods and 
protocols were developed for "internetworking'' these different packet switched 
networks. This work lead to the transmission control protocol (or "TCP") and the 

30 internet protocol (or "IP**) which became the TCP/IP protocol suite. Although the 
TCP/IP protocol suite, which is the fotmdation of the Internet, is known to those 
skilled in the art, it is briefly described below for the reader's convenience. 
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As shown m Hgure 2, the TCP/IP reference model 220 includes a 
physical layer 221, a network access layer 222, an internet layer 223, a transport 
lay^ 224, and an application layer 225. Each of these layers is briefly introduced 
below. 



The physical layer 221 defines the interface between a data 
transmission device (e.g., a computer) and a transmission medium (e.g., twisted 
pair copper wires, 

co-axial cable, optical fiber, etc.). It specifies the characteristics of the 
transmission medium, the nature of the signals, the data rate, etc. 

The network access layer 222 defines the interface between an end 
system and the network to which it is attached. It concerns access to, and routing 
data across, a network. Frame relay is an example of a network access layer. 

The internet layer 223 functions to permit hosts to mject packets 

into any network and have them travel independently to the destination machme 

(which maybe on a different network). Since these packets may travel 

independently, they may event anive in an order other than the order in which 

theyweresent. Higher layers can be used to reorder the packets. Thus, the main 

fimction of the internet kyer 32 b is to deUver(e;g., route) IP packets to^t^^ 
destination. 

The transport layer 224 is an end-to-end protocol. For example, the 
25 transmission control protocol (or 'TCP") is a reliable connection-oriented 

protocol that allows a byte stream origmating on one machine to be deHvered, 
without error, on any other machine on the Internet. More specificaUy, the TCP 
protocol fragments an incoming data stream into discrete messages, each of 
which is passed to the internet layer 223. At the destination, the TCP protocol 
30 reassembles the received messages into an output stream. 

The TCP/IP model 220 does not have session and presentation 
layers. Instead, an appUcation layer 225 contains all of the higher-level protocols 



20 
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that are used to support various types of end use applications (e.g., the simple 
mail transfer protocol (or "SMTP") for e-mail, the file transfer protocol (or 
"FTP"), etc.). 

5 The TCP/IP model does not define what occurs below the intemet 

layer 223, other than to note that the host has to connect to the network using ; 
some protocol so that it can send IP packets over it. This protocol varies from 
host to host and network to network. 

10 Basically, each of the layers encapsulates, or converts, data in a 

higher layer. For example, referring to Figure 4, user data 400 as a byte stream is 
provided with a TCP header 402 to form a TCP segment 410. The TCP segment 
410 is provided with an IP header 412 to form an IP datagram 420. The IP 
datagram 420 is provided with a network header 422 to define a network-level 

15 packet 430. The network-level packet 430 is then converted to radio, electrical, 
optical (or other) signals sent over the transmission medium at a specified rate 
with a specified t3^ of modulation. 

The TCP header 402, as illustrated in Figure 5, includes at least 
20 twenty (20) octets (i.e., 160 bits). Fields 502 and 504 identify ports at the source 
and destination systems, respectively, that are rising the connection. Values in 
the sequence nimiber 506, acknowledgement mamber 508 and window 516 files 
are used to provide flow and error control. The value in the checksum field 518 is 
iised to detect errors in the TCP segment 410. 

25 

Figures 6A and 6B illustrate two (2) alternative IP headers 412 and 
412', respectively. Basically, Figure 6A depicts the IP protocol (Version 4) that 
has been used. Figure 6B depicts a next generation IP protocol (Version 6) that, 
among other things, provides for more source and destination addresses. 

30 

More specifically, referring to Figure 6A, the four (4) bit version 
field 602 indicates the version nimiber of the IP, in this case, version 4. The 4-bit 
Intemet header length field 604 identifies the length of the header 412 in 32-bit 



BNSDOCID: <WO 02195e5Al J_> 



wo 02/19585 

PCT/USO 1/24925 

-7- . 

words. The 8-bit type of service field 6o6 indicates the service level that the IP 
datagram 420 should be given. The 16-bit total length field 608 identifies the 
totallengthof theIPdatagram42oinoctets. The 16-bit identification field 610 is 
used to help reassanble fi-agmented user data carried m multiple packets. The 
5 3-bit flags field 612 is used to control firagmentation. The 13-bit fi-agment offset 
field 614 is used to reassemble a datagram 420 that has become fi-agmented. The 
8-bit time to live field 616 defines a maximum time that tAe datagram is aUowed 
to exist within the network it travels over. The 8-bit protocol field 618 defines the 
higher-level protocol to which the data portion of the datagram 420 belongs. The 
10 16-bit header checksum field 620 permits the integrity of the IP header 412 to be 
checked. The32-bitsourceaddressfield322containstheIPaddressofthe 
sender of the IP datagram 420 and the32-bit destination address field contains 
the IP address ofthe host to which the IP datagram 120 is being sent. Options 

and padding 626 may be used to describe special packet processing and/or to 
15 ensure that the header 412 is a complete multiple of 32-bit words. 

Referring to Figure 6B, the four (4) bit version field 602 indicates 
the version number of the IP. in this case, version 6. The 4-bit priority field 628 

enablesasendertoprioritizepacketssentbyit. The 24-bit flow label field 630 is 
used by a source to label packets for v^*ich special handling is requested. The 

16-bit pa3doad length field 632 identifies the size of data caiiied in the packet. 
The 8-bit next header field 634 is used to mdicate whether another header is 

presentandifso,toidentifyit. The 8-bit hop limit field 636 serves to discard the 
IP datagram 420 if a hop Ihnit (e.g., the number of times the packet is routed) is 
25 exceeded. Also provided are 128-bit source and destination address fields 322' 
and 324', respectively. 

Having described the TCP/IP protocol stack 220, the routing of a 
TCP/IP packet is now described. 

A TCP/IP packet is communicated over the Internet Cpr any 
internet or intranet) via routers. Basically, routers m the Internet use destination 
address information (Recall fields 624 and 624'.) to forwaixi packets towards 
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their destination. Routers interconnect different networks. More specifically, 
routers accept incoming packets from various connected networks, use a look-up 
table to determine a network upon which the packet should be placed, and routes 
the packet to the determined network. 

Figure 7, which includes Figures 7A through 7C, illustrates the 
communication of data from a sender, to a receiver, using the TCP /IP protocol 
stack. Referring first to Figure 7A, an application protocol 702 prepares a block 
of data (e.g., an e-mail message (SMTP), a file (FTP), user input (TELNET), etc.) 
400 for transmission. Before the data 400 are sent, the sending and receiving 
applications agree on a format and encoding and agree to exchange data (Recall, 
e.g., the peer-to-peer communications depicted with dashed lines in Figure 1.). If 
necessary, the data are converted (character code, compression, encryption, etc.) 
to a form expected by the destination device. 

The TCP layer 704 may segment the data block 400, keeping track 
of the sequence of segments. Each TCP segment 410 includes a header 402 
containing a sequence nimaber (recall field 506) and a firame check sequence to 
detect errors. A copy of each TCP segment is made so that if a segment is lost or 
damaged, it can be retransmitted. When an acknowledgement of safe receipt is 
received from the receiver, the copy of the segment is erased. 

The IP layer 706 may break the TCP segment into a number of 
datagrams 420 to meet size requirements of networks over which the data will be 
communicated. Each datagram includes the IP header 412. 

A network layer 708, such as frame relay for example, may apply a 
header and trailer 422 to frame the datagram 420. The header may include a 
connection identifier and the trailer may contain a frame check sequence for 
example. Each firame 430 is then transmitted, by the physical layer 710, over the 
transmission mediimi as a sequence of bits. 



.0219585A1.L> 



o 



"^OOVVJSHS PCT/LSOl/24925 

-9- 

Figure 7B iUustrates the operation of the TCP/IP protocol stack at a 
router in the network. The physical layer 712 receives the mcoming signal 430 
from the transmission medium and interprets it as a frame of bits. The network 
(e.g., frame relay) layer 714 then removes the header and trailer 422 and 
processes them. A frame check sequence may be used for eiror detection. A 
connection numbermay be used to identify the source. The network layer 714 
then passes the IP datagram 420 to the IP layer 718. ' 

The IP layer examines the IP header 412 and makes a routing 
decision (Recall the destination address 324, 324'). A local line control (or 
"LLC") layer 720 uses a simple network management protocol (or "SNMP") and 
adds a header 750 that contains a sequence number and address mformation. 
Anothernetwork layer 722 (e.g., media access control (or "MAC")) adds a header 
and trailer 760. The header may contain address mformation and the ti-aUer may 

5 contain a frame check sequence. The physical layer 724 then ti^mits the frame 
450 over another transmission medium. 

Figure 7C iUustrates the operation of the TCP/IP protocol stack at a 
receiver. The phyacallayer 732 receives the signals from the ti-ansmission 
medium and interprets them as a frame of bits. The network layer 734 removes 
the header and trailer 760 and processes them. For example, tiie frame check 
sequence in the trailer maybe used for error detection. The resulting packet 440 
is passed to the tiransport layer 736, which processes the header 750 for flow and 
error controL The resulting IP datagram 420 is passed to tiie IP layer 738, which 
removes the header 412. Frame check sequence and other conti-ol infonnltion 
may be processed at this point. 

The TCP segment 410 is then passed to the TCP layer 740, which 

removes the header 402 and may check tiie frame check sequence, an the event 
of a match, tiie match is acknowledged and in tiie event of a mismatch, the packet 
is discarded.) The TCP layer 740 tiien passes the data 400 to the appUcation 
layer 742. If tiie user data was segmented (or fragmented), tiie TCP layer 740 
reassembles it. Finally, tiie application layer 742 performs any necessary 
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transformations, such as decompression and decryption for example, and directs 
the data to an appropriate area of the receiver, for use by the receiving 
application. 

5 § 1.3 EXPECTED DRIVERS OF FUTURE NEIWORK DESIGN 

The present inventors believe that most of tlie world's networks are, 
or wiU be, based on the Internet Protocol (or "IP**), There are at least three (3) 
assumptions underlying this belief. First, IP separates applications (or services) 

10 from transport (e.g,, data link technology). The present inventors believe that 
value added services will be IP-based, due in part to favorable price-performance 
curves of IP access technology and the way in which IP can inter-operate with 
other technologies. Second, IP quality of service (or "QoS") is emerging. These 
QoS mechanisms can be applied to the specific applications and services (e.g,, 

15 audio-visual multicast, conferencing, high speied access such as via DSL, IP 
derived lines, IP tdephony, IP fax, IP Centrex, Internet service provider (or 
"ISP") services such as e-mail, Internet access, authorization, authentication and 
accotmting, and billing, and unified messaging) of individual customers. Various 
types of applications may demand various levels of quality of service. For 

20 example, a voice over Intemet application may require low delays, but may 
tolerate some packets being dropped, to the extent that such dropped packets 
cannot be perceived or are not annoying to users. This is because it would be 
pointless to retransmit erroneous padcets in such a real-time application. Data 
transport may tolerate delays but will not tolerate transmission errors. Video 

25 over the Intemet wiU require high bandwidth but may tolerate some dropped 
packets (again, to the extent that such dropped packets wotild not be perceived 
by, or be annoying to, a customer). Third, data competitive (or certified) local 
exchange carriers (or "DLECs") — that is, companies that provide high speed 
access to the Intemet — currently provide integrated IP services using 

30 asynchronous transfer mode (or "ATM") transport. The present inventors believe 
that as lower cost link layer technologies are deployed, such as gigabit Ethernet 
for example, DLECs will abandon ATM. 
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With this background in mind, the present inventors propose a 
multi-service local access and transport area (or "LATA") IP network with the 
following two (2) design goals in mind. First, it should be sunple for existing and 
potential customers to use the proposed LATA IP network. Second, the LATA IP 
5 network should be robust and flexible, while having a low operating cost. The 
present inventors believe that customer simpUcity can be achieved by (i) 
eliminating or minimizing changes to existing layer i and 2 customer interfaces 
(so that existing customers maybe retained) and (ii) providing new, low cost, 
high value IP interfaces to customers (such as Fast Ethernet and Gigabit 
lo Ethernet). The present inventors further believe that the LATA IP network can 
be robust, flexible, and have low operatmg costs by (i) minimizing complexity (by 
isolating subsystems with different component technologies and separating 

application functionaUty from the underlying transport network), (ii) mimmi2d^ 
operations, (iii) providing the abiHty to route traffic for services which have 
15 different topology and volume assumptions, and (iv) ensuring reUability by using 
off-the-shelf components and standard protocols (thereby eliminating 
customization) and by providing redundant equipment and feciUties. 

The LATA IP network envisioned by the present inventors may use 
20 off-the-shelf routers. These routers may function to (i) provide access to 
customers, (ii) interconnect networks, and/or (iii) provide routing between 
intranetwork elements. Thus, the LATA IP network may use three (3) different 
types of routers. In the LATA IP network, access routers may be distributed 
towards the edge of the network and may provide individual customer IP 
25 interfaces into the network. Thus, the access router may act as a universal IP 
edge device for diverse customer access methods. Interconnection routers may 
be centralized wifli the IP LATA and may provide a small number of (e.g., high 
bandwidfli) external interfaces to the other carrier's (or enterprise customer's) 
network(s). Finally, routers maybe deployed, as needed, throughput the IP 
30 LATA to consolidate traffic and to minimize the cost of traffic transport between 
elements of the IP LATA 
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§ 1.3.1 CHALLENGES IN ACCESSING AN EDGE ROUTER 

One aspect of the present invention concerns the challenge of 
aggregating a ninnber of physical connections from a number of potentially 
5 diverse custorners, for connection to an edge router- For example, 

standards-based routers that can handle 128 Gbps bandwidth are currently 
available. However, such routers cannot accommodate the physical connections 
of the tens or himdreds of thousands of individual services that they could 
otherwise accommodate- For example, assuming that customers had a very high 
10 end 10 or 100 Mbps service (or communications access links capable of such 
service levels), such routers could process the data flow from 12,800 or 1,280 
customers, respectively, but could not accommodate those numbers of physical 
connections. Naturally, a larger niraiber of physical connections (e.g., for lower 
end service(s)) could not be accommodated. 

15 

Digital stibscriber line access multiplexers (or "DSLAMs**) may be 
used to concentrate traffic in asynchronous digital subscriber line (or **ADSL*') 
implementations by using time division multiplexing. Basically, a DSLAM can 
accept twisted copper pairs supporting ADSL service and provide them on virtual 

20 channels on a shared common communications medium, such as an OC3 (e.g., 
155-52 Mbps) fiber channel. However, an asynchronous transfer mode (or 
"ATM") switch is needed to switch these physical connections to virtual channels, 
thereby necessitating an ATM switch port for each customer connection. Aside 
from physically requiring a lot of space, losing a DSLAM for this purpose would be 

25 expensive on a per port basis. Thus, improved techniques are needed to 

aggregate physical connections, for example, for presentation to an access router. 

Another aspect of the present invention concerns the challenge of 
separating customer services from customer access technologies (e.g., DSL, 
30 Frame Relay, Gigabj^e Ethernet) . In this way, a variety of services could be 

provided to a variety of potential customers without regard for the way in which 
such potential customers access the IP LATA network. 
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§2. SUMMARY 

The present invention may provide an aggregation unit to aggregate 
physical connections from customers for presentation to an access router and to 
5 de-aggregate traffic from a shared link(s) from the access router. These functions 

may be accomplished by configuring logical ports of the aggregation unit such 
that each has a unique layer 2 (e.g., MAC) address or som^ other unique bit string 
(also referred to as "context information") associated with it. Such context 
information may replace, at least to some extent, layer 2 (e.g., address) header 

10 information on packets accepted by the logical port. In one embodiment, the 
context information may include customer-specific information, mfonnation 
locating the logical port within the network, and/or class of service information. 
This context information, which depends solely on the logical port, canbe 
extended to include quality of service mfonnation. Such quaUty of service 

15 i^ormationmayconveynetworkrequirementsinherentinthe application with 
which an inbound packet(s) is associated, arid maybe derived fit)m layer 3 and 
layer 4 information in the inbound packet(s). Thus context information may 

include a packet-indepraident part associated with a logical port and a 
packet-dependant part determined from an inbound packet(s). The term «bit 
20 string" or -context information" is not intended to be Ihnited to contiguous bits, 
and is to include non-contiguous bits as can be appreciated from Figure 36. 

If it can be assumed that IP addresses are globally unique, the layer 
2 (e.g., MAO address of the customer device connected with the port can be 
25 associated with, and therefore determined from, the IP address of the attached 
device. Otherwise (or in addition), the layer 2 (e.g., MAC) address of the 
customer device connected with the port can be determined using some type of 
address resolution technique (e.g., resolving the address with a protocol, such as 

ARP for example, typically by broadcasting a request for an address), and/or 
30 snooping (e.g., examining the layer 2 source address of an inbound (ingress) 
packet). Thus, for example, if the IP addresses are dynamically assi^ed to 
customer devices, then the aggregation unit may periodically poll (e.g., via an 
address resolution protocol or «ARP" broadcast) the attached device(s) for its 
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layer 2 (e.g., MAC) address, and/or iriay examine the layer 2 soiirce address of 
inbound packets. 

When a packet is received from a customer, layer 2 header 
information (e.g., the source and destination layer 2 (e.g., MAC) addresses) may 
be removed and a imique bit string (or **context information"), a part of which is 
associated with a logical port or interiface (which is associated with the physical 
port), and a part of which is based on layer 3 and/ or 4 information in the packet, 
may be added. Preferably, these operations will not alter the "footprint of the 
packet. To reiterate, these bits that replace layer 2 header information (e.g., the 
source and destination layer 2 (e.g., MAC) addresses), may be referred to as 
"context information". Again, context information may include a 
packet-independent part associated with a logical port and a packet-dependant 
part determined from an inbound packet(s). Traffic received at the logical ports 
is then aggregated onto a high bandwidth physical link(s) to the access router. 

When a packet is received from the access router, the aggregation 
unit forwards it to the logical port associated with at least some bits of the bit 
string (i.e., of the context information) that reside in the place of the layer 2 
20 (address) header. The destination layer 2 (e.g., MAC) address (or the other bits 
in the place of the layer 2 address) is then replaced with the layer 2 (e-g., MAC) 
address of the customer device associated with the port. To reiterate, the layer 2 
(e.g., MAC) address of the customer device may be derived from the layer 3 
destination address (if it can be assxamed that layer 3 addresses are globally 
25 unique), or, alternatively may have been determined using an address resolution 
technique, and/or snooping. 

The present invention may also support multicast groups by 
checking at least a part of the imique bit string (i.e., context information) which 
30 had been inserted in the layer 2 header space to determine whether or not the 
customer associated with that port is permitted to join the multicast group. The 
present invention may monitor the service provided to a group of customers, that 
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group of customers being defined by at least a portion of the unique bit string 
(i.e., context information) whidi had been mserted in the layer 2 header space. 

The present invention may also function serve to limit or control 
access to various services thereby performing a firewall function. In this regard, 
an access router may permit or deny a packet based on at least a portion of the ' 
unique bit string (i.e., context information) which had been mserted m the layer 2 
header space. The present invention may further function to faciHtate the 
provision of different quality of service levels. Aparticular quality of service may 
be indicated by at least a part of the unique bit string (i.e., context infonnation) 
which had been inserted in the layer 2 header space. 



The present mvention may also function to enable virtual private 
networks since it preserves layer 2 header information or a unique bit string (or 
15 context information) which had been inserted in the layer 2 header space. 

§3. BRIEF DESCRIPTION OF THE DRAWINGS 

■ Figure 1 illustrates the way in vdiich network communications 
20 schemes maybe described by a stack of protocols. 

Figure 2 compares the OSI reference model and the TCP/IP 
protocol smte. 

25 Figure 3 illustrates internet protocol (or "IP") global addressing. 

Figure 4 illustrates the manner in which data is encapsulated by a 
TCP header, an IP header, and a network header in accordance with the TCP /IP 
protocol suite. 



Figure 5 illustrates the fields of a TCP header. 
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Figures 6A and 6B illiistrate the fields of Version 4 and Version 6, 
respectively, of the IP header. 

Figiires 7A through 7C illustrate the transmission of data over a 
5 network in accordance with the TCP/IP protocol suite. 

Figiore 8 is a high level diagram of a network that the present 
invention may be used to access. 

10 Figure 9 is an example of the network of Figure 8 in which services 

and applications are shown separated from tramsport. 

Figure 10 is a high level diagram of processes that may be 
performed by various aspects of the present invention. 

15 

Figure 11 illustrates how various access technologies may interface 
with an access router of the network of Figure 8 or 9. 

Figure 12 illustrates fields of an Ethernet frame. 

20 

Figure 13 illustrates an exemplary data structure specification of a 
unique bit string (or context information) that may be used in the present 
invention and that maybe administered in accordance with a network-wide plan. 

25 Figure 14 is a high-level block diagram of an exemplary aggregation 

ttnit. 

Figtire 15 illiistrates a physical implementation of an exemplary 
aggregation unit. 



30 



Figure 16 illustrates an exemplary implementation of management 
cards in the exemplary aggregation imit of Figure 15. 



BNSDOC10:<W0 0219585A1 I > 



PCT/US«,/24925 

. . -17- 

Figure 17 mustrates an exemplary implementation Of customer 
facing interfaces (or ports) in the exemplary aggregation unit of Figure 15. 

Figure 18 illvistrates an exemplary implementation of network 
5 facing interfaces in the exemplary aggregation unit of Figure 15. 

Figure 19 is a high level flow diagram which 'iUustrates operations 

which may be performed as a packet enters an IP network via an aggregation 
device and an (ingress) access router, and as a packet leaves an IP network via an 
o (egress) access router and an aggregation device. 

Figure 20 is a flow diagram of an exemplarymethod that maybe 
used to effect a logical port configuration function. 

Figure 21 is a flow diagram of an exemplary method that may be 
used to effect a logical port aggregation function. 

Figure 22 is a flow diagram of an exemplary method that may be 
used to efifect a link de-aggregation function. 

Figure 23 is a flow diagram of an exemplary method that may be 
used to effect a multicast group monitoring function. 

Figure 24 is a flow diagram of an exemplary method that may be 
used to efifect a customer group monitoring fianction. 

Figure 25 iUustrates an exemplary data structure of access control 
information that may be used by an exemplary access router. 



Figure 26 is a flow diagram of an exemplary method that may be 
used to effect an access control function. 
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Figures 27A and 27B are flow diagrams of exemplary methods that 
may be used to effect a virtual private network addressing function as a packet 
enters the network (ingress) and as a packet leaves the network (egress), 
respectively. 

Figure 28 is a flow diagram of an exemplary method that may be 
iised to enable various service levels- 
Figure 29 illustrates an exemplary table that may be used by an 
10 exemplary aggregation device, to configure logical ports. 

Figure 30 illustrates an exemplary table that may be used by an 
exemplary aggregation device, to convert a port layer 2 address (or information in 
the place of the layer 2 address) to a customer device la3^r 2 address- 

15 

Figure 31 illustrates an exemplary table that may be used by an 
exemplary aggregation device, to associate multicast networks or subnetworks 
with a virtual private network. 

20 Figure 32 illustrates an exemplary table that may be used by an 

exemplary access router, to control access to a network or to a network location. 

Figure 33 illustrates an exemplary table, which may be used by an 
exemplary access router, to encapsulate a packet so that layer 2 address 
' 25 information (or information in the place of the layer 2 address header) may be 
preserved. 

Figure 34 illustrates an exemplary table, which may be used by an 
^emplary access router, to determine a layer 2 (e.g„ MAC) address of a customer 
30 device based on a layer 3 address and/or bits in the place of information (e.g., 
address information) in a layer 2 header. 
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Figure 35 iUustrates an exemplary packet which may be sent by a 
customer and received by an aggregation imit 

Figure 36 iUustrates the modification, by an exemplary aggregation 
5 unit, of a packet sent from a customer and bound for a network. 

Figure 37 illusti-ates the modification, by an 'exemplary access 
router, of a packet sent fi-om a customer, as forwarded by an aggregation unit, 
and bound for a network. 



o 



§ 4. DETAILED DESCRIPTION 



The present invention involves novel methods, apparatus and data 
structures for permitting customers to access a network, such as an IP network, 
5 and to help provide certain services. The following description is presented to ' 
enable one skilled in tiie art to make and use tiie mvention, and is provided in the 
context of particular appUcatioris and tiieir requirements. Various modifications 
to the disclosed embodiments will be apparent to those skilled in the art, and the 
general principles set forth below may be applied to other embodiments'and 
appUcations. Thus, tiie present invention is not intended to be lunited to the 
embodunents shown and the inventors regard their invention as the following 

disclosed methods, apparatus and data structures and any other patentable 
subject matter. 

In the following, an exemplary environment in which tiie invention 
may operate is described in § 4.1. Then, functions tiiat may be performed by the 
present invention are inti-oduced in § 4.2, Thereafter, processes, stiiichores, 
metiiods and data structiires tiiat may be used to effect those ftmctions are ' 
described in § 4.3. Thereafter, the end-to-end processing of a packet in a system 
including exemplary aggregation units and access routers is described in § 4.4. 
Finally, some conclusions regarding various aspects of tiie present mvention are 
provided in § 4.5. 
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ENVIRONMENT IN WfflCH INVENTION MAY OPERATE 



Figure 8 is a high level diagram of an enviroranent 8oo in which the 
present invention may operate. This environment Boo may include a LATA IP 
5 network Sio, additional networks 820 such as an enterprise network, a portal 
Internet service provider (or "ISP") network, a peer ISP network, and an existing 
layer 2 service provider network. The networks 820 may 'be interconnected with 
the LATA IP network 810 via interconnection router(s) 816. Customers 830, 
such as homes and businesses, may be connected with the LATA IP network 810 
10 via **access routers'' 812. Finally, routers 814 maybe provided within the LATA 
IP network 810 for consoUdating traffic and minimzing traffic ti^^ 
example. One aspect of the present invention concems aggregating physical 
connections from the elastomers 830 for presentation to an access router 812. 

15 Figure 9 illustrates how the LATA IP network 810 can be used to 

separate transport facilities firom applications and services. Again, the LATA IP 
network 810 may be ddBbaed, at least in part, by the access routers 812, the 
routers 814, and the interconnection routers 816. Notice that the networks of 
others, such as America On-line, UUNET, SBC, GTE, Sprint and Yahoo may 

20 conmiimicate with the LATA IP network 810 via the interconnection routers 816. 
As shown in the IP application section of Figure 9, the LATA IP network 810 may 
provide firewall functionality (via access router 812), V/IP GW (voice over 
Internet - gateway), next generation switch functionality (via routers 814), AAA 
(authentication, authorization, and accoimting), web caching and video storage 

25 facilities (via routers 814). The other companies may provide chat, e-mail, V/IP 
GK (voice over Internet - gatekeeper) and web hosting functionality via their own 
networks, and the interconnection routers 816. 

§4.2 inJNCTIONS WHICH MAY BE PERFORMED BY THE PRESENT 
30 INVENTION 

The present invention may function to aggregate physical 
connections from customer (also referred to as "dient") devices (Recall, e-g., 830 
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of Figure 8.) for presentation to an access router (RecaU, e.g., 812 of Figure 8.) 
and to de-aggregate traffic from a shared link(s) ftom the access router. (Note 
that a given customer may have multiple devices. Note also that a given customer 
may have more than one service type/level.) The present invention may also 
function to limit or control access to various services thereby performing a 
fire-waU function. The present invention may also function to enable virtual 
private netvsrorks by preserving layer two (2) address information or a unique bit 
string (or context mformation) in the place of at least some information in the 

layer 2 header. The present invention may further function to help provide 
different quality of service levels. FinaUy, the present invention may function to 
control access to multicast groups. 



§ 4.3 EXEMPIARY PROCESSES, DATA STRUCTURES, METHODS 

AND ARCHITECTURE FOR EFFECTING THE FUNCTIONS OF 
15 THE PRESENT INVENTION 

§4.3.1 EXEMPLARY HIGH LEVEL COMPONENTS AND 

PROCESSES 

^° ^ig^e 10 illustrates connections to, and processes that may be 

performed by, an aggregation unit 1010 of the present mvention, as well as 

" processes vwhichmaybe performedbyan access router 812. The aggregation unit 
1010 maybe coupled with an access router 812 by one or more high bandwidth 
Unksi020. Redundantlinksi02omaybeused. Further,linksio5afroma 
25 number of customers 1030 are coupled with ports 1040 of the aggregation unit 
1010. 

The aggregation unit 1010 may perform a port configuration 
process 1012 for creating an address table 1060 that maybe used for enabling 
30 customer addressing, a port aggregation process 1014 which uses information in 
the address table io6o (See e.g.. Figure 29 below.) to manage packets received 
from the ports 1040, a shared link de-aggregation process ioi6 which uses 
information in the address table 1060 (See, e.g.-, Figure 30 below.) to manage 
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packets received from the access router 812, and a multicast group monitoring 
process 1018 for managing access to multicast information using a table 1019 
(See, e-gv Figure 31 below.). 

5 Notice that the port configuration process 1012 and the multicast 

group monitor process 1018 may be controlled by, or operate in accordance with, 
an administration entity 1092 which may administer a plan 1090, as indicated by 
the dashed lines. 

10 The access router 812 may perform an access control process 1082, 

based on an access control list 1083 (See, e.g., Figure 32 below.), a virtual private 
network addressing process 1084 which may use an encapsulation lookup table 
: 1085 (See, e.g., Figure 33 below.), a group service level process 1086, and a group 
monitor process 1088 for monitoring the service provided to a group of 

15 customers. These processes may be controlled by, or rhay operate in accordance 
with, the plan 1090 of the administration entity 1092 as indicated by the dashed 
lines. As shown, a portion of the shared link de-aggregation process 1016* may be 
performed by the access router 812 based on a client device address table 1089. 
(See, e.g.. Figure 34 below.) 

20 

Having described, at a Mgh level, processes that may be carried out 
by the aggregation imit 1010 and the access router 812, exemplary technologies 
for accessing the aggregation unit 1010 will be described in § 4.3.2. llien, an 
exemplary plan 1090, which may be produced and maintained by the 

25 administration entity 1092 will be described in § 4.3.3. Thereafter, an exemplary 
architecture of the aggregation imit 1010, as well as exemplary data structures of 
the address table(s) 1060 and other aggregation unit table(s) 1019, and 
exemplary methods for effecting the processes of the aggregation unit 1010 will 
be described in § 4.3.4. Finally, an exemplary architectiare of the access router 

30 812, as well as exemplary data structures of the access control list 1083, an 
encapsidatioii lookup table 1085 and an a client device addressing table 1089, 
and exemplary methods for effecting the processes of the access router 812 will 
be described in § 4.3.5. 
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§ 4.3-2EXEMPLARY ACCESS TECHNOLOGIES 

Figure 11 iUustrates the manner in which various types of access 
technologies may interface with an access router 812', via an aggregation unit 
1010. To emphasize that the present mvention accommodates different access 
technologies, and to illustrate its compatibiHty with legacj) access technologies. 
Figure 11 illustrates how the aggregation units 1010 of the LATA IP network 
be used with existmg (or "legacy") facihties (such as xDSL over ATM 1110 and 
native ATM 1140), as well as new access technologies (such as WDM of gigabit 
Ethernet (GbE) 1150). . 



can 



In the xDSL over ATM access technology mo, a customer's 
computer 1112 can access an aggregation unit 1010 via an XDSL transmission 
15 ^t-remote at the customer premises, which transmits an ATM logical circuit (or 
VPI/VCI) m7 over twisted pair supporting digital subscriber line (or "xDSL") 
service 1116, to a digital subscriber line access multiplexer (or "DSLAM") 1130, 
which connects to a fiber port (for example, OC-3) 1132 of the aggregation unii, 
via an ATM logical circuit. 



In the ADSL over ATM access technology 1120, a customer's 
computer U22 and Internet telephone 1123 can simultaneously access the 
aggregation unit 1010 via an ADSL transmission unit-remote ("ATU-R") 1126, 

over twisted pair m6 supporting asymmetrical digital subscriber Ime (or 
25 "ADSLl service, the digital subscriber Ime access multiplexer (or "DSLAM") 1130 
and the fiber port 1132. 

In the ATM access technology 1140, a customer's router 1142 can 
access the aggregation unit 1010 via an ATM logical circuit 1144 that connects to a 
30 high bandwidth port (for example, a 44-736 Mbps DS3 digital line) 1146 on the 
aggregation unit loio. 
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As noted in § 1.3.1 abovie, the present inventors believe that using 
DSLAMs with ATM ports is not the best or most cost-effective access technology- 
More specifically, the present inventors have recognized that IP routed Ethernet 
can offer greater bandwidth, faster failover, simpler operations, better scalability, 
5 and lower cost than ATM/SONET, Further, IP routed Ethernet may provide 
redxmdant management, bus and power. 

i ' . 

Having introduced the ways in which legacy access facilities can 
interface with ah aggregation unit 1010, an example of how an aggregation unit 

10 1010' of the present invention may be used to permit new access facilities (such as 
WDM of gigabit Ethernet 1150) is now described. In the example in Figure 11, a 
customer's computer 1152 may interface with the LATA IP network via an optical 
network interface device (or "NID'O 1154, over 10/100 Base optical fiber 1156, to a 
pedestal (for splicing cables) 1158, that connects to a remote a wave division 

15 multiplexer (or "WDM") 1160, which connects to a gigabit Ethernet (or "GBE") 
port 1020' of the aggregation unit loio*. 

Notice that Ethernet LANs are employed. This is due to their 
perceived cost and performance advantages over other access technologies (such 
20 as those just listed above). Although Ethernet is known to those skilled in the art, 
it will be described briefly in § 4.3.2.1 below for the reader's convenience. 

§4.3.2.1 ETHERNET 

25 Ethernet is a well-known and widely deployed local area network 

(or ''LAN") protocol, Ethernet has a bus (as opposed to a ring or star) topology. 
Devices on an Ethernet LAN can transmit whenever they want to — if two (2) or 
more packets collide, each device waits a random time arid tries again. More 
specifically, as defined in IEEE 802.3, Ethernet is a LAN with persistent carrier 

30 sense multiple access (or "CSMA") and collision detection (or "CD"). If a device 
wants to transmit, it "listens" to the cable (hence the term "carrier sense"). If the 
cable is sensed as being busy, the device waits of the cable to become idle. If the 
cable is idle, any connected device can transmit (hence the term "multiple 
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access"). If two (2) or more devices begin to transmit simultaneously, there will 
be a collision which wiU be detected (hence the term "collision detection"). In the 
event of a collision, the devices causing the collision will (i) terminate their 
transmission, (ii) wait a random time, and (iii) tiy to transmit again (assuming 
that the cable is idle). Accordingly, a CSMA/CD cable or bus has one (1) of three 
(3) possible states - contention (or coUision), transmission, or idle. Ethernet 
LAN interfaces, like some other LAN interfaces, may have a 'promiscuous mode" 
under which all frames are provided to a device, rather than just those addressed 
to the device. 



The IEEE 802.3 frame structure 1200 (or MAC Sublayer Protocol) 
is iUustrated in Figure 12. The source and destination addresses 1230 and 1240, 

respectively, may be six (6) bytes (or 48 bits) long. The second most significant' 
bit is used to distmguish local addresses from global addresses. Thus, 46 bits are 
15 available for addresses (or about 7 x io« unique addresses). Accordingly, any 
device can uniquely address any other device by usmg the right 48-bit address - 
it is up to the network layer to figure out how to locate the device associated with 
the destination address. The 48-bit address will be discussed in greater detail in 
§ 4.3.2.1.1 below. 



The two (2) byte length of data field 1250 indicates the number of 
bytes (bet^yeen o and 1500) present m the data field 1260. At the end of the 
frame is the four (4) byte checksum field 1280 that can be used to detect errors m 
the frame. Between the data field and the checksum field is a pad field 1270 of 
25 variable length. This pad field 1270 is provided because valid fr^es 1200 must 
be at least 64 bytes long. Thus, if the data field 1260 is less than 46 bytes, the pad 
field 1270 is used to make both it and the data field 1260 at least 46 bytes. 



§4.3.2.1.1 MAC ADDRESSES 

Recall that IEEE 802.3 may use fi^es 1200 which may include 
48-bit addresses. These addresses maybe referred to as media accesscontrol (or 
"MAC") addresses. Basically, each device that may be connected to a network or 
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the Internet has an assigned unique MAC address. (Some bits of the MAC 
address are assigned to various device manufactures. The manufactures then 
ensure that each device manufactured by it has a imique MAC address.) 

5 Although using Ethernet as an access technology to the LATA IP 

network introduced above is desirable from a cost and performance standpoint, 
there are certain challenges, met by the present invention, to using this access 
technology. More specifically, imlike legacy access technologies such as 
asynchronous transfer mode (or ^^ATM") which use end-to-end connections, the 

lo Internet protocol does not — it is only concerned with the next hop. This presents 
a challenge to the owner or operator of the LATA IP network because it cannot 
control the layer 2 (or MAC) and layer 3 (or IP) addresses. For example, because 
: the MAC address is assigned to a hardware device such as a NIC, if the customer 
changes their NIC, their MAC address will change. If the customer adds another 

15 computer and a router, the MAC address will change to that of the router. 

Regarding control by the owner or operator of the LATA IP network 
of the IP address, such an owner or operator may provide service to an Internet 
service provider (or "ISP") for example: Such ISPs typically reserve a number of 

20 IP addresses that are shared by all of their customers. In this way, the ISP can 
have more customers than reserved addresses. More specifically, the dynamic 
host control protocol (or **DHCP") permits the ISP to assign a temporary IP 
address (also referred to as a "dynamic address") to a subscriber. Even the option 
of providing each of an ISP's customers with its own static IP address would 

25 become unmanageable since every time the ISP added, deleted, or changed the IP 
address of a customer, the LATA IP network owner and/or operator would have 
to reconfigure the network. 

In view of the foregoing, the present invention should function to 
30 aggregate a nimiber of physical connections to one or more high bandwidth links 
to an access router. Preferably, the present invention should facilitate the 
deployment of Ethernet access technology. In this regard, the present invention 
should (i) maintain the identity of the customer device, and (ii) maintain address 
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iiiformation for communications between the customer device and the access 
router 812'. This may be done in accordance with an administered plan, such as 
the one described in § 4.3.3 below. The aggregation unit 1010 of the present 
mvention may accompHsh these goals by identifying a physical or logical port to a 
customer and enabling the addressing of the port. Thus, in the present invention, 
tiie layer 2 (e.g., MAC) address is only unique witiiin the segment to the access 
router 812'. ' 

§4.3-3 PLAN FOR AGGREGATION ADDRESSING AND 

CONTROLLING THE PROVISION OF SERVICE LEVELS 



The present invention may use a plan for forwarding a customer's 
IP ti-affic that (i) maintains tiie identity of the source of the packet (e.g., a 

customer), (ii) maintains infonnation regardmg where the ti-affic of tiie customer 
15 device enters and exits the LATA IP network, (iii) accommodates a]i layer 2 
access technologies, and (iv) permits the provisioning of service levels to be 
controlled. An exemplary plan tiiat maybe used to accomplish these goals is 
described below. 



4.3.3.1PLAN FOR IDENTIFYING A PORT TO A CUSTOMER AND TO A 
CUSTOMER DEVICE 



A plan 1090', which may be prepared by an administiration entity 
1092, may identify a logical port of the aggregation unit 1010 to each distinct 
25 logical circuit of traffic from a customer device. In this way, each logical port may 
be configured with enough information to identify tiie customer that it supports, 
and to identify tiiat port in context of all other logical ports in the IP LATA 
network. 
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4-3.3-11 EXEMPLARY SPECIFICATION FOR IDENTIFYING A 
CUSTOMER'S TRAFFIC 

5 Anexemplaiy set of infoimatioh 

the physical interface to which the logical port is attached, the corresponding 
logical circuit information for the particular access technology, a imique identifier 
within the LATA IP network, the customer (for example, a service provider) that 
sources the IP traffic to the IP LATA network, and the virtual private network (or 
10 "VPN") that is the source or destination of IP traffic on the logical circuit. 

An exemplary specification for such an information set may use: (i) 
a 32-bif logical port identifier (or address), which may identify 4,294,967,296 
logical ports; (ii) a 24-bit organizational universal identifier (or "OUI") for the 
15 customer (or "VPN-OUI''), which may identify 16,777,216 customers; and (iii) a 
32-bit VPN identifier (or VPN-Index), which may identify 4,294,967,296 VPNs 
perVPN-OUI. 

The 32-bit logical port identifier (or address) may comprise 16 bits 
20 that define one of 65,536 geographic locations, 4 bits that identify one of sixteen 
(16) physical units to which the lo^cal port is attached, and 12 bits that assign 
one of 4096 cardinal mmibers to the logical port within its physical unit. 
Naturally, the bits of the logical port identifier may be provisioned based on 
ingress points, or expected future ingress points, to the network. 

25 

4.3.3.1.2 EXEMPLARY PLAN FOR CONVEYING A CUSTOMER'S 
IDENTIFYING INFORMATION 

The present invention may convey the customer addressing 
30 information among network elements of the LATA IP network using a customer 
addressing protocol that wholly encapsulates the customer's original IP traffic. 
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The customer addressing protocol may obtain information from the 
logical port corresponding to a customer's logical circuit. 

The customer addressing protocol may be in a form of an existing 
5 layer 2 (e.g., MAC) address or some other unique bits (or context infonnation) in 
the place of, or in addition to the layer 2 address. 

i . 

Figure 13 shows an exemplary data structure 1310 for conveying a 
customer's identifying information 1312 and customer device addressmg 
iQ information 1314. In an exemplary protocol, the data structure 1310 is part of a 
modified Ethernet frame, specifically 88 bits of the 96 bits of addressing space of 
the header. The exemplary protocol replaces the addressing infonnation y^dth a 
24-bit field for the VPN-OUI, a 32-bit field for the VPN-Jndex, and a 32-bit field 

for the logical port on which the traffic entered the network (or 'logical ingress 
15 port"). This is illustrated in Figure 36. By conveying this infonnation within a 
modified Ethernet frame, the aggregation unit and access router can use any data 
communications tedmology that supports Ethernet encapsulation of an IP 
packet. That is, the footprint of the Ethernet frame is not changed. 



20 



This mfoimation, in its complete or partial form, may remain 
attached to the origmal BP packet throughout the LATA IP network. 



Fmally, since the information 1310 does not depend on the contents 
of a received packet(s), but rather only on the logical port, this part 1310 of the 
25 context infonnation can be thought of as a packet-independent part. 

4.3.3-2PLAN FOR IDENTIFYING A CUSTOMER'S SERVICE 
LEVELS 

3° "^epresentinventionmayprovideforvariouslevelsofservice. In 

the example disclosed, two kinds of service levels are provided: i) quality of 
service; and ii) class of service. QuaUty of service (or "QoS") defines the network 
requirements necessary to satisfy certain perfonnance requfrements associated 
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with an IP application, for example voice over IP. Quality of service may be 
derived from layer 3 and/or 4 information iii a received packet(s) and can 
therefore be thought of as a packet-dependent part of the cont^ information. 
Class of service (or "CoS") defines the priority that a customer's IP traffic has 
5 within a network. Class of service levels may be customer-selected and can be 
thought of as a service bundle or service level agreement (which maybe ordered 
and, optionally, modified by the customer). Since class of 'service does not 
depend on information in a received packet(s), it can be thought of as a 
packet-independent part of the context information. 

10 

The group service level process 1086 may require service level 
information (in addition to the customer device addressing and customer service 
agreement information)- The service level plan may be prepared by an 
administration entity 1092, may identify a packet's QoS by the nature of its IP 
15 appUcation (Recall packets layer 3 and/or 4 information.), and may identify the 
same packet's CoS by reference to additional customer information (e.g-, 
associated with the logical port). 

4.3.3.2.1 EXEMPIJ^RY SPECIFICATION FOR IDENTIFYING A 
20 CUSTOMER'S SERVICE LEVELS 

Given that there is a finite set of popidar IP applications, and that a 
taxonomicsJ classification of these applications yields a finite set of application 
types, an exemplary set of QoS levels may include 256 levels, each of which 
25 corresponds to a type of IP application. Upon receipt of customer traffic, the 
aggregation unit may determine an 8-bit QoS type by examining the layer 3 
protocol field and/ or the layer 4 port field. 

Since CoS may be customer-selected, it may be part of the customer 
30 information set associated with a logical port. The CoS for a logical port may use 
an 8-bit or 16-bit designation, which may serve 256 or 65,536 possible CoS levels, 
respectively. 
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4.3.3.2.2 EXEMPLARY PROTOCOL FOR CONVEYING A 
CUSTOMER'S SERVICE LEVELS 

The present invention may convey the service level information 
5 among network elements of the LATA IP network by extendmg the context 

information mduding the customer identifying and customer device addressing 

information to further convey service level information which may include, or be 
derived from, quality of service and/or class of service information. 

^° ^^Sure 13 shows an exemplary data structure for conveyii^ service 

level information 1320 as an extension to a customer identifymg and customer 
device addressing part 1310 of tiie context mformation. In tiiis exemplary 
embodiment, the context information is extended to include an 8-bit QoS field 
and an 8-bit or 16-bit CoS field. The 8-bit (supporting 256 levels) QoS fidd fits 

15 into tiie remaining unused bits (88+8=96) oftiie 96-bit Etiiemet addressing 
space. The 8-bit or 16-bit dass of service (CoS) information may be placed into 

tiieTagIDfieldofan8o2.iQVLANtag,attachedtotiieEthemetframe. (See, 
e.g.. Figure 36.) Alternatively, if an 8-bit CoS is used, tiie CoS information mJy 
be placed into the LLC SSAP (Imk layer conti-ol - subsystem service access point) 
20 field of the Ethernet header. 

As witii tiie basic context mformation including customer 
identifying infomiation i3i2 and customer device addressing information 1314, 
tiie context information as extended to include service level information 1320 ' 
25 may remain attached to tiie original IP packet tiiroughout tiie LATA IP network. 

§ 4.3.4EXEMPLARY AGGREGATION UNIT 

In tiie foUowing, an exemplary architecuire of tiie aggregation unit 
30 1010' is described in § 4.3.4.1 witii reference to Figures 14 tiirough 18. Then, an 
exemplary data stiiicture for tiie address table 1060 is described in § 4.3.4.2'witii 
reference to Figures 29 and 30. Thereafter, exemplary metiiods for effecting the 
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processes of the aggregation unit are described in § 4.3.4.3 with reference to 
Figures 20 through 24. 

§4.3.4.1 EXEMPIJVRYARCfflTECTURE 

Figure 14 is a high-level block diagram which illustrates 
connections to an exemplary aggregation unit 1010'. On the right side of the 
aggregation unit 1010', 100 10 Mbps full duplex ports 1040' per 1 Gbe port or 10 
100 Mbps fuU duplex ports per Gbe port may be provided for lines 1050'. On the 

10 left side of the aggregation unit 1010', a gigabit Ethernet (or "GBE'') link 1020' is 
provided to the access router (not shown). The aggregation unit 1010' may use 
time division multiplexing, space division multiplexing (or channelizing), 
statistical multiplexing, or another type of mtdtiplexing to aggregate traffic from 
the lines 1050' to the link(s) 1020'. The aggregation imit 1010' may be a line 

15 speed, non-blocking, imit. In this case, assuming sufficient bandwidth on the 
link(s) 1020', 12,000 half-duplex (or 6,000 fuU-duplex) 10 Mbps customers or 
1,200 half-duplex (or 600 full-duplex) 100 Mbps customers could be 
accommodated by a 120 GBE access router. Alternatively, the aggregation imit 
1010' may concentrate traffic. By providing access facilities capable of providing 

20 bandwidth that should meet the demands of most foreseeable applications, the 
present invention win allow service levels provided to the customer to be changed 
without changing the access facilities. Thus, for example, a customer could 
request changes in available bandwidth in real time (e.g., via a web interface) that 
change the configuration of the logical port (Recall, e.g., plan part 1312 and/or 

25 i320of Figure 13.) to which the customer is connected. 

Figure 15 illustrates an exemplary chassis implementation for an 
aggregation unit 1010'. Network facing interfaces 1520 terminate the high 
bandwidth link(s) 1020' to the access router. Management cards 1510 may be 
30 provided for storing information associated with the ports 1040' (e.g., the logical 
interfaces associated with each port). As will be described in § 4.3.4.3 below, this 
information maybe assigned dioring an initial configuration and/or during 
ongoing polling operations. A first management card 1510a mirrors a second 
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1510b. In this way, if one management 1510 card faUs, it can be removed, a new 
card can be installed, and information can be copied to the newly mstalled card, 
thereby shnplifying maintenance and elhninating any downtime. To the left of 
the management cards 1510 are ports 1040' for terminating lines from the 
5 customers. 

In each case, the ports 1040' and network mterfaces 1520 have no 
initial configuration. Upon startup or installation, they query the active 
management card 1510 for configuration based on their location m the chassis. 
Thus, for example, a logical mterface can be assigned to ports based on their 
location withm the LATA IP network (Recall plan part 1314 of Figure 13.), rather 

than solely based on the physical mterface card. The bits assigned may be within 
a range of bits (or one or more bits of the context information) associated with 

services with which the customer wants. (Recall administration plan 1090' of 
15 Figure 13.) As discussed above with reference to Figure 14, m one exemplary 
embodunent, the ports 1040 maybe 10 or 100 Mbps cards, while the network 
interfaces 1^20 may be 1 Gbps cards. 



lO 



20 



Figure 16 is an exemplary management card 1510'. The 
management card includes a data plane 1620, a management plane 1630, flash 
memory 1610, mdicators 1640 and 1650, such as visual mdicators like LEDs for 
example, and management interfaces 1660.. 

Figure 17 is an exemplary customer mterface card 1700 which 
25 mdudes a data plane 1710, a management plane 1720, and a number of hot 

swappable customer ports 1040". Similarly, Figure 18 is an exemplary network 
interface card 1800 which includes a data plane 1810, a managerr^ent plane 1820, 
and a number of hot swappable network mterface ports 1520'. 

2° Basically, processor(s), application specific mtegrated circuit(s), 

programmable logic array(s), and/or other hardware and/or software may be' 
used to effect the processes of the aggregation unit. 
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§4.3.4.2 EXEMPLARYADDRESS TABLE DATA STRUCTURE 



Figures 29 and 30 illustrate exemplary address tables 1060' and 
1060", respectively, which maybe generated, maintained, and used by the 
5 aggregation unit 1010. More specifically, these tables 1060' and 1060" may be 
configured by the port configuration process 1012. The table of Figure 29 may be 
used by the port aggregation process 1014, and the table of Figure 30 may be used 
by the shared link de-aggregation process 1016. 

10 As shown in Figure 29, the table 1060' may include a column 2910 

of logical interface or port niunbers, a column 2920 of virtual private network 
identifier organizational universal identifiers (VPN-OUI), a column 2930 of 
virtual private network identifier indexes CVPN-Index), a column 2940 of 
ciistomer layer 3 (e.g., IP) addresses, a colimm 2956 of class of service levels, a 

15 column 2960 of multicast access control list (ACL) groups, a coluum 2970 of 
quality of service (QoS) profiles, a column 2982 of virtual path identifiers CVPIs), 
a column 2984 of virtual channel identifiers CVCIs), a column 2986 of permanent 
virtual circuits (PVCs), and a column 2988 of Ethernet ports. The logical port 
number 2910 may be associated with a physical interface 1040' location on the 

20 chassis. (Recall plan part 1314 of Figure 13.) The VPN-OUI 2920 and VPN-Index 
2930 are also assigned to the port Gogical interface) 1040' by the management 
card 1510. This assignment maybe done during initial configuration of the 
aggregation unit ioio*. Referring to both Figure 13 and Figure 29, notice that: 
the VPN-OUI column 2920 may coirespond to 24 bits of the context information; 

25 the VPN-Index column 2930 may correspond to 32 bits of the context 

information; the VPI 2982, VCI 2984, PVC 2986, and/or ethemet port 2988 
colimins may correspond to other bits of the context information; and the service 
level 2950, multicast access control list group 2960, and/or quality of service 
profile 2970 colunms may correspond to other various bits of the context 
30 information. To reiterate, the table 1060' of Figure 29 may be used by the port 
aggregation process 1014 to aggregate packets from a number of logical interfaces 
or ports onto a link to the access router 812. 



BNSDOCID: <WO. 



.02195e5A1J_> 



lO 



wo 02/19585 

PCT/USOl/24925 

-35- 

As Shown in Figure 30, the table io6o» may include a column 3010 
of logical mterfaces (eachof which may correspond to a physical port), a column 
3020 of layer 2 (e.g., MAC) addresses assigned to each of the network-side 
mterfeces or ports of the aggregation unit, a column 3030 of IP addresses with 
which one or more client device maybe associated, a column 3040 of subnet 
masks which may be used to mask out non-relevant portions of a layer 3 (e g IP) 
address, and a column 3050 of cUent device layer 2 (e.g., MAC) addresses, a' 
layer 3 (e.g., IP) address of column 3030 and a client device layer 2 (e g MAC) 

address of a client of column 3050 may have a one-to-one or one-to-ma^y 
relationship. For example, if a single device, such as a customer computer or a 

company router is always comiected to the port, then its IP address and its static 
associated layer 2 (e.g., MAC) address will be provided in columns 3030 and 

3050. If, on the other hand, a customer is assigned a dynamic IP address (by its 

Internet service provider (or -ISP'O and that customer is comiected with the port 
15 through its ISP, for example), then tiie IP address of column 3050 may have the 

layer 2 (e.g., MAC) address of a customer currently associated with that IP 
address (of the ISP's router for example). The information in these columns 
3030 and 3050 maybe populated by information returned in response to address 
resolution broadcasts (e.g.,ARPs), and/or by infonnation gleaned by examining 
mbound packet(s) (or "snooping"). The address table io6o» may be used by the 
shared link de-aggregation process 1016 for example, toforward a packet to the 
proper logical interface or port and to replace the packet's layer 2 (e g MAC) 

destmationaddress (or otherinfonnationin the place of the layer 2 destination 

address)withthatofthecustomercurrentlyassociatedwiththelayer3(eg IP) 
25 address. 



§4.3.4-3 EXEMPLARY METHODS FOR EFFECTING 
AGGREGATION UNIT PROCESSES 

In the foHowing, an exemplary method that maybe used to effect 
the logical port or interface configuration process 1012 is described in § 4 3 4 3 1 
with reference to Figures 13 and 20. An exemplary method that maybe used to 
effect the logical port or interface aggregation process 1014 is described in § 



20 



30 
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4.3-4-3-2 with reference to Figures 21 and 29. An exemplary method that may be 
used to effect the shared link de-aggregation process 1016 is described in § 
4.3.4-3-3 with reference to Figures 22 and 30. Finally, an exemplaiy method that 
may be used to effect the multicast group monitoring process lOiS is described in 
5 § 4-3.4-3.4 with reference to Figures 23 and 31. Generally speaking, processor(s), 
appUcation specific integrated circuit(s), programmable logic array(s), and/or 
other hardware and/or software maybe used to effect the processes of the access 
router. 

10 §4.3-4.3.1 EXEMPLARY LOGICAL PORT OR INTERFACE 

CONFIGURATION METHOD 

Figure 20 is a flow diagram of an exemplary method 1012* which 
may be used to effect the port configuration process 1012. As shown in optional 

15 step 2010, customers are coupled with ports. More spedfically, lines, such as 
fiber optic lines or copper lines for example, carrying customer traffic are 
terminated at the ports 1040 of the aggregation unit. A logical port is associated 
, with a physical port or a physical port location as shown in block 2020. (Recall 
plan part 1314 of Figure 13.) Customer identifying information and logical 

20 ingress port information (Recall parts 1312 and 1314 of Figure 13.) may be 

provided, as a imique bit string (or context information), to the logical port, as 
shown in step 2030. Further, dass of service information (Recall part 1320 of 
Figure 13.) may be provided to the logical port. Thus a packet-independent part 
of context information is associated with the logical port at this point. The 

25 method 1012' learns the MAC address of an attached device by, e.g., periodically 
polling the attached device(s) for its layer 2 (e.g., their MAC) address(es) using its 
currently assigned layer 3 (e.g., IP) address (e.g., ARPing), and/or by examinii^ 
the contents of an inboimd packet(s) (e.g., snooping) as shown in step 2050. 
(Recall column 3050 of Figure 30. The layer 2 address (e.g., the MAC address) of 

30 the customer device is then associated with the layer 3 address (e.g., IP address), 
as shown in step 2060. (Recall colimms 3030 and 3050 of Figure 30.) The 
method 1012' is left via RETURN node 2080 and maybe executed as logical ports 
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are added. At this point, the columns of the tables illustrated in Figures 29 and 
30 shotdd be popidated. 

Note that the method 1012' can determme the physical port location 
5 and unique bit string (Recall steps 2020, 2030) at one time, for example upon 
startup ofthe aggregation unit or when a new customer is added to the . 

aggregation unit. However, the determination of the layei^ 2 addresses of the 
attached device(s) then associated with the layer 3 addresses should take place 
periodically. In one alternative, aU of the ports periodicaUy poll attached 
device(s) for its layer 2 address. This polling should occur frequently enough so 
when the access router 812' asks it (using for example, an address resolution) for 
these addresses, they are up to date. 

■ - I 

§4.3.4.3.2 EXEMPLARY PORT AGGREGATION METHOD 

Figure 21 is a flow diagram of an exemplary method 1014' that may 
be used to effect the port aggregation process 1014' in response to a packet(s) 
received from a customer and entering the network. In step 2110, 
packet-dependent context information (Recall, e.g., QoS of Figure 13.) is 
determined based on (e.g., layer 3 and/or layer 4 information of) the packet(s) 

received. ^ step 2120, infonnation in the original layer 2 (e.g., MAC addresses) 
header ofthe packet is removed and the context information is added. The 
context information may include the part assigned to the logical port or interface 
(packet-mdependent part) and the part determmed m step 2110 
(packet-dependent part). (See, e.g.. Figure 36.) For example, the layer 2 (e.g., 
MAC) address assigned to the customer device (as weU as the layer 2 (e.g MAC) 
address assigned to the port) maybe replaced with a unique bit string (or context 
information) (e.g., correspondmg to the values in columns 2920, 2930, 2950 and 
2960 of Figure 29) associated with the logical port or interface number (See e g 
column 2910 of Figure 29.) associated with the physical port 1040 to vduch ihe ' 
customer is connected, as weU as values (e.g., in columns 2970, 2982, 2984, 2986 
and 2988 of Figure 29) derived from layer 3 and/or layer 4 information in the 
packet(s). nien, in step 2130, traffic on all ofthe logical ports or interfaces is 
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aggregated on to logical channels on a high bandwidth physical link to an access 
router 812'. This aggregation maybe done via multiplexing, such as space 
division multiplexing (channelizing via, e.g., frequency division multiplexmg, 

wavelength division multiplexing, etc.), time division multiplexing, or statistical 
5 multiplexing for example. As discussed above, in one exemplary embodiment, 
this aggregation maybe done at line speed, without concentration. The method 
1014' is then left via RETURN node 2140. To reiterate. Figure 36 illustrates an 
example of how an incoming packet may be modified by this process 1014. 

10 §4.3-4-3.3 EXEMPLARY SHARED LINK DE-AGGREGATION 

METHOD 

Figure 22 is a flow diagram of an exemplary method 1016' which 
may be used to effect the shared link de-aggregation process 1016 which maybe 
15 executed in response to a packet being received from the network (destined for a 
customer). If a packet has been received from the network, in step 2220, the 
packet is placed on the logical port or interface (See, e.g., column 3010 of Figure 
30.) associated with the information in the layer 2 header of the packet. (Recall, 
e.g., part 1314 of Figure 13.) Then, in step 2230, the destmation layer 2 (e.g., 

20 MAC) address of the packet is changed to that of the customer device associated 
with the logical port or interface. More specifically, referring to Figure 30, the 
layer 2 (e.g., MAC) address of the network side port in column 3020 will be 
replaced with the layer 2 (e.g., MAC) address of the customer device in colimm 
3050 based on the logical port 3010 (and IP address 3030). The method 1016* is 

25 then left via RETURN node 2240. 

§4-3.4-3.4 EXEMPLARY MULTICAST GROUP MONITORING 
PROCESS 

30 Figure 23 is a flow diagram of an exemplary method 1018* that may 

be used to effect the multicast group monitoring process 1018. Although 
multicasting using TCP/IP is known to those skilled in the art, it is introduced 
here for the reader's convenience. 
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RecaU from Figure 6A that version 4 of the mtemet protocol header 
includes 32-bit source and destination addresses. Figure 3 iUustrates IP 
compHant addresses. Eveiy host and router on the Internet has a unique IP 
address. Network numbers are assigned by the Network Information Center (or 
"NIC") to avoid conflicting addresses. This address mcludes a network number 
and a host number. Currently, there are four (4) classes of address formats. 

Qass A permits up to 126 networks with up to 16 million hosts each. ClassB 
permits up to 16,382 networks with up to 64,000 hosts each. Class C permits up 
to 2 million networks with up to 254 hoste each. Qass D permits multicasting. 
Unlike IP address classes A, B and C, multicasting addresses are not assigned and 
cannot be reserved or controlled by the owner and/or operator of the LATA IP 
network. These addresses are controlled by routers which route multicast 
packets in accordance with the Internet group multicast protocol (or "IGMP"). 
15 Thus, the owner and/or operator of the LATA IP network cannot prevent 

outsiders from joining a multicast group by provisioning or controlling multicast 
addresses. To secure the multicast groups, the LATA IP network owner and/or 

operatormaymanagethemulticastaddressspacesothatsome are reserved for 
specific groups of customers. In this vy^y, the aggregation unit 1010' can deny 
20 requests to join a multicast group. 

More specifically, referring to step 2310, the method 1018' may 
examine the bits of the unique bit string (or context information) that are 
relevant to multicasting. (Recall, e.g., plan parts 1312 class of service 1320 of 

t5 Figure 13.) If it is determined that the bit(s) indicate a permission (for a 

customer) to join a particular multicast group, the aggregation unit will provide 
the packet to the port (corresponding to the customer) as shown in steps 2320 
and 2330. Otherwise, if it is determined that the bit(s) do not indicate a 
permission for a customer to join the particular multicast group, the aggregation 

o unit will block the packet from the port corresponding to the customer. Although 
not shown, the packet may be forwarded to a port which forwards packets related 
to network security to a monitoring and/or storage faciUty. The method 1018' is 
then left via RETURN node 2340. 
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Figure 31 is a table which illxistrates how multicast networks and/or 
sub-networks can be associated with a virtual private network ("VPN"). More 
specifically, at least some bits of the VPN-pUI 3140 arid VPN-Index 3150 (i.e., 
5 those bits not masked out by subnet mask 3130) can be associated with a 

multicast access control list group 3110 having associated multicast address 3120. 

i ' . 

§ 4.3.5EXEMPLARY ACCESS ROUTER 

10 Recall from Figure 10 that the access router may perform an access 

control process 1082 based on an access control list 1083. A data structure of an 
exemplary access control list is described in § 4.3.5.1 below with reference to 
Figures 25 and 32. Then, an exemplary method that maybe used to effect the 

access control process is described in § 4.3.5.2 with reference to Figures 26 and 
15 32. Fiirther recall from Figure 10 that the access router may also perform a 
virtual private network adi-essing process 1084, a group quality of SCTvice 
process 1086 and a group monitor process 1088. An exemplary method that may 
be used to effect the virtual private network addressing process 1084 is described 
in §4-3«5-3 below with reference to Rgiires 27 and 33. An exemplary method 
20 that may be used to effect the group service level process 1086 is described in 
§ 4-3-5-4 below with reference to Figure 28. Finally, an exemplary method that 
may be used to rffect the group monitor process 1088 is described in § 4.3.5.5 
below with reference to Figure 24. Generally speaking, processor(s), application 
specific integrated circuit(s), programmable logic array(s), and/or other 
25 hardware and/ or software may be used to effect the processes of the access 
router. 

§4.3-5.l EXEMPLARY ACCESS CONTROL LIST DATA STRUCTURE 

30 Recall from the description ofFigure 13 in §4.3.3 above that a 

common plan 1090' may be used such that various values of at least some bits of 
the context information correspond to various services or customer service 
agreements. (Recall parts 1312 and dass of service 1320 ofFigure 13.) Figure 25 
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fflustrates a data structure of an exemplary access control list 1083' which may be 
used by the access router 812 to permit or deny access to services, locations, etc. 
More specificaUy, the Hst 1083' includes a column 2510 which Usts various values 
of at least some bits of the context information (RecaU, e.g.. Figure 13.) which 
correspond to various services or customer service agreements. As shown, these 
services may include various services offered by the owner and/or operator of the 
LATA IP network, such as virtual private networks with or without Internet 
access, Internet access only, etc. This information may correspond to the VPN- 

OUI 3225, VPN-Index 3230, protocol 3235, L4 port 3240, type of service 3245 
and service level 3250 columns of Figure 32. Ranges of the layer 3 (e.g., IP) 

source addresses are depicted in the column 2520 (See somx» IP addre^ 3205 
andmask32io columns ofFigure 32.), and ranges ofthe layer 3 (e.g., IP) 
destination addresses are depicted in the column 2530 (See destination IP 
address 3215 and mask 3220 columns of Figure 32.). Based on the service bit(s) 
; in column 2510, the layer 3 source address and/or the layer 3 destmation 
address, the access router 812 can permit or deny a packet, as indicated by 
column 2540. The access router 812 may use these permit/deny instructions to 
dedde whether to route or drop a packet. As can be appreciated, in this way, 

various values of bit(s) of the context mformation (as vvell as the layer 3 source 
and/or destination address) may be used to permit or deny access to various 
services. The last instruction in the access control list may be a deny command 

(if the packet was not already permitted). An exemplary method that may be 
carried out the access roirter is described m § 4.3.5.2 below. 

§4.3-5.2 EXEMPLARYACCESS CONTROL METHOD 

Figure 26 is a flow diagram of an exemplary method 1082' which 
maybe used to effect an access control process 1082. First, as shoWn in step 
2610, any bit(s) of the context information and/or any bit(s) of layer 2, 3, and/or 
4 addresses that are relevant to access control are exammed. (These bits maybe > 
taken from the packet using filtering (e.g., masking), etc.) In decision branch 

point 2620, it is determined whether or not the bit(s) indicate a permission to 
access a network, a network location, or a service for example. (Recall 
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permit/deny column 2540 of Figure 25-) If the bit(s) do indicate permission to 
access, the packet is routed as shown in step 2630, and the method 1082' is left 
via RETURN node 2640. Otherwise, the packet is not routed, and the method 
1082' is left via RETURN node 2640, Although not shown, any packets not 
5 routed may be forwarded to a port which forwards packets to a network security 
monitoring and/or storage facility. 

§4.3-5-3 EXEMPLARYVIRTUAL PRIVATE NETWORK 
ADDRESSING METHOD 

10 

Figures 27A and 27B are flow diagrams of exemplary methods 
1084a' and 1084b' which may be used to effect a part of the virtual private 
network addressing process 1084. However, the need for these methods will be 
introduced first* 

15 

Recall from Figure 3 that different classes (e.g.. A, B, or C) of IP 
addresses can have a different maximtim niraiber (e.g., 126, 16,382 or 
2,ooo>ooo) of networks. Although not shown in Figure 3, some of these 
addresses are not uniquely assigned, are not routed by most standard internet 
20 routers, and can be used by anyone. Thus, more than one company may be using 
the same private IP address. 

The owner and/or operator of the IP LATA network may want to 
provide virtual private network services. However, as just described, private IP 

25 addresses are not necessarily globally unique. The access router 812 may solve 
this problem as follows. Referring to Figure 27A, at step 2710, at least a portion 
of an inboimd packet (e.g., at least a part of the context information) maybe used 
to identify members of a virtual private network. (Recall Figures 29 and 31 and 
part 1312 of Figure 13.) Thus, for example, a company could access the LATA IP 

30 network from more than one access router 812' via more than one aggregation 
unit loio'. However, eaich of the ports of the aggregation unit 1010' with which 
the company was connected would include context information having one or 
more bits which could serve to laniquely identify that compan3r*s virtual private 
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network. (Recall, plan part 1312 of Figure 13.) This step need only be done once 
(Recall step 2030 of the port configuration method illustrated in Figure 20) At ' 
decision branch node 2720, it is determined whether or not a packet is received 
fromacustomer(tobeforwardedtothenetwork). If so, a new layer 3 address 
5 ^capsulates the packet so that its unique bit string (or context information) 

from which a layer 2 (e.g., MAC) address of the client device can be derived ' 
Olecall, e.g., the tables of Figures 29 and 30), is preserved' as shown in step 2730 
If this encapsulation were not done, the layer 2 address would change over each " 
segm^t of the network. Thus, the encapsulation preserves the concept of group 
> ;^--"n,servicelevels,etc.overtheentireIATAIPnetworka^^ 

tl^ edge of the network. Figure 33 illustrates an exemplaxy encapsulation lookup 
tableio85'. Notice that a new layer 3 destmation address 3350 can be derived 
from at least a part of the VPN-OUI 3330 and the VPN-Index 3340 This 
desthxation address is that of the access router (also refeircd to as an "egress 
access router'' associated with the client device having the original layer 3 
destination address). 

'^'SureayillustratesanencapsulatedlPpacketszooafterrouW 
has been determined. Notice that the layer 3 somo^ address 3710 is that of the 
mgress access router (i.e., the router performing the encapsulation) and can be 
detemnned from column 3316 of the Uble io85' Hgure 33. Notice also that the 
layer 3 destination address 3720 is that of the ^ access muter (i.e.. the access 
router assodated «ith the client device having the original layer 3 destination 
address3730). '"'eforegomg described the exemplary virtual private network 
addressing method 1084a' fiom the perspertive of a packet entering the network 
Below, a method 1084b- is des^ibed &om the perspective of a packet leaving the' 
network. ^ 

Figure 27B is an exemplary method 1084b' that maybe used to 
effect another part of the virtual private network addressing process. At decision 
branch node 2740, it is determined whether or not a packet is received from the 
network (to be forwarded to a customer). If so, the access router removes the 
encapsulation, as shown in step 2750. The original layer 3 destination address 
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3730 may be used with the dient device address table 1089' (See column 3410 of 
Figure 34.) to determine a new VPN-OUI (See column 3420.), VPN-Index (See 
column 3436.), and the layer 2 (e.g., MAC) address of the destination client 
device (See colmnn 344o.) as shown in steps 2760 and 2770. If the client device 
5 address table 1089' does not include entries corresponding to the layer 3 
destination address, an address resolution request (e.g., an "ARP") may be 

broadcast to request such information as shown in steps 21760 and 2765. The 
packet may then be forwarded to the aggregation device as shown in step 2780 
before the method io84bMs left via RETURN node 2790. 

10 

Note that although not shown, before the packet is forwarded 
towards the aggregation imit, the egress access router can perform access control 
and group quality of service processes based on at least some of the new bits (e.g., 
the new VPN-OUI and VPN-Index). In this way, if the destination customer 
15 (chent) has a lovy^ service level (e.g., service type or quahty), then services which 

were not limited by the ingress access router (since the source customer (device) 
has a higher level of service) may be limited by the egress router. 

§4.3.5.4 EXEMPLARY METHOD FOR FACILITATING THE 
20 PROVISION OF VARIOUS SERVICE LEVELS 

Figure 28 is a flow diagram of an exemplary method 1086' which 
maybe used to effect the group quality of service process 1086. First, as shown in 
step 2810, any bit(s) of the context information and/or any bit(s) of layer 2, 3, 

25 and/ or 4 addresses that are relevant to service level (Recall, e.g., plan part 1320 
of Figure 13.) are examined. (Actually, the quality of service part of the context 
information may have aheady accounted for layer 3 and/or layer 4 information in 
the packet(s). If so, only those bits of the context information relevant to service 
level need be examined.) These bit(s) maybe extracted from the context 

30 information usmg filtering (e.g., masking), etc. In dedsion branch point 2820, it 
is determined whether or not the bit(s) indicate a particular service level. (See, 
e.g., colimm 3250 of Figure 32.) 
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If the bitCs) indicated ai particular service level, the packet may be forwarded to a 
queue level associated ymth the level of priority appropriate for that service levd 
as shown m steps 2820 and 2830. The method 1086' is then left via RETURN 
node 2850. 

5 

§ 4.3.5.5 EXEMPLARY GROUP MONITORING PROCESS 

The present invention may also allow packets to or from a 
particular group of customers (e.g., customers from the same company, 
10 customers purchasing particular quaUty of service guarantees, etc.) to be copied 
for monitoring. Figure 24 is a high level flow diagram of an exemplary method 
1088' which may be used to effect the group monitoring process 1088. As shown 

in step 2410, the method 1088' may examine the bitCs) of the unique bit string (or 

context information) and/or layer 2, 3, and/or 4 addresses to define the groiq) of 
15 customers (RecaU the access control list of Figure 25 and part 1312 of Hgure 13 ) 
to be monitored. If it is determined that the bit(s) mdicate that the customer 
belongs to the group being monitored, the aggregation unit will provide a copy of 
the packet to a "monitoring" logical port (not shown) as shown in steps 2420 and 
2430. Otherwise, if it is determined that the bit(s) do not indicate that the 
customer belongs to the group being monitored, the packet is simply processed as 
usual. Themethodio88'isthenleftviaRETURNnode2440. Notice that this 
method 1088' is transparent from the perspective of the client devices. 

Having described exemplary embodiments of data structures which 
25 maybe used by, and methods which maybe performed by both the aggregation 
unit and the access router, an example which iUustrates the end-to-end 
processing of a packet in a system employing these exemplary devices is set forth 
in § 4.4 below 



20 
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§4.4 END-TO-END PROCESSING OF A PACKET IN A SYSTEM 

INCLUDING EXEMPLARY AGGREGATION UNITS AND ACCESS 
ROUTERS 

5 An example wWchillixstrates how a packet may be sent from a 

elastomer to the network (via an aggregation unit 1010' and an (ingress) access 
router 812') and how a packet is sent from the network to a customer (via an 
(egress) access router 812' and an aggregation unit 1010*) is described below, 
with reference to Figiares 19, 35, 36 and 37. 

10 

A packet may be provided from a customer, not shown, to an 
aggregation device 1010'.^ Referring to Figure 35, the packet 3500 is received 
from the customer 1030' within a layer 2 header that includes a layer 2 (e.g., 
MAC) destination address 3522 and a layer 2 (e.g., MAC) source address 3524, 
15 and may include other fields 3525, 3526, 3527. The layer 3 header 3530 includes 
a protocol field 618', a port field 3532, a layer 3 source address field 622', a layer 
3 destination address field 624', and a type of service field 606'. 

Referring to Figure 19, if the packet is riot an address resolution 
20 protocol (or ARP) packet, as shown by decision block 1902, the aggregation xmit 
1010' changes the layer 2 address information 3522 and 3524 of the layer 2 
header' 3520 (and potentially other information of the layer 2 header 3520, such 
as field 3526 for example) to the ingress context information (e g., the unique bit 
string) associated with the logical port or interface (and derived from the received 
25 packet(s)) as shown in block 1906. (Recall Figiare 29 and step 2120 of Figure 21 
and Figure 13.) Figure 36 illustrates the transformation of a packet effected by 
step 906. This new packet 3600 is then passed onto the (ingress) access router 
812' as shown in block 1908- 

30 StiU referring to Figure 19, at the access router 812*, an access 

control list (Recall, e.g.. Figures 25 and Figure 32O policy maybe applied as 
shown in block 19^0, and the packet may be allowed or denied based on the 
access control list policy as shown by decision block 1912. Recall from Figure 25 



BNSCX3CID: <WO 021958SA1 J_> 



15 



20 



25 



30 



WO 02/19585 

PCT/USOl/24925 

-47- 

that the access control Ust may use at least a portion of the unique bit string (or 
context information) replacing the layer 2 header infonnation (See, e.g., column 
2510 of Figure 25 and columns 3225 and 3230 of Figure 32.) and/or at least a 
portion of the layer 3 address infonnation (See, e.g., columns 2520 and 2530 of 
; Figure 25 and columns 3205, 3210, 3215 and 3220 of Figure 32.). If the packet is 
demed access, it maybe forwarded to a security port «M2'' as indicated by block 

1914. If, on the other hand, the packet is allowed, a type ot service may be 
re^tten as a "service level" based on layer 2, 3, and/or 4 infonnation as shown 

mblocki9i6. (See,e.g.,column3245ofFigure32andfield376oofFigure37.) 

Next, as shown in block 1918 and decision block 1920, a rate 
limitingpoHcymaybeappUedandenforced. (See, e.g., column 3250 of Figure 
32.) Ifthecustomer(client)deviceisexceedingtheratespecifiedinitsclassof 
service level agreement, the packet(s) may be forwarded to a service level 
agreement port "Ml" as shown by block 1922. If, on the other hand, the customer 
(chent) device is within the rate specified in its dass of service level agreement 
the packet may then be forwarded to an encapsulation interface as shown by ' 
block 1924. 

Next, as shown by blocks 1926 and 1928, the layer 2 and 3 
addresses,aswellastheservicelevelareread. (See,e.g.,Figure32.) Then,as 

shown by block 1930, the packet is encapsulated with layer 3 infonnation and 
service level bits are set. This encapsulation is shown in Figure 37, wherein the 
layer 3 (e.g., IP) source address 3710 is derived from column 3310 of Figure 33 
the layer 3 (e.g., IP) destination address 3720 is derived from colmmi 3350 of ' 
Figure 33, and the service level value 3760 is derived from the class of service and 
quahty of service values. (See, e.g., column 3245 of Figure 32 and part 1320 of 
Figure 13.) The layer 2 source address 3740 and the layer 2 destination address 
3750 may also be written as shown in Figure 37. The layer 2 source address 3712 
IS known and the layer 2 destination address 2714 may be generated from a 
lookup table in the (ingress) access router 812'. The packet may then be 
forwarded to the network-facing mterface of the access router as shownbyblock 
1932 
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The packet(s) may then be forwarded to the network based on its 
service level. (Recall Figiire 28 and part 1320 of Figure 13.) For example, there 
may different queues that have different associated priorities. Padcets may be 
5 provided to a particijlar queue based on their service level. The padcets then go 
to the core IP network 1940 based on some quetiing or scheduling discipline. 

Having described the way in which an aggregation tmit 1010' and an 
(ingress) access router 812' may handle packets from a customer destined for the 
10 core IP network 1940, the way in which an (egress) access router 812* and an 
aggregation imit 1010 ' may handle packets from the core IP network 1940 
destined for a customer is now described. 

As shown by block 1952, a packet(s) received from the core IP 
15 network 1940 is forwarded to a de-encapsxilation interface where, as shown by 
block 1954, it is de-encapsulated. (Recall, e.g., step 2750 of Figure 27B.) More 
specifically, referring back to Figure 37, the layer 2 transport and IP 
encapsulation may be stripped from the received packet. 

20 Then (assuming that layer 3 (e.g., IP) addresses are globally 

unique), the layer 2 destination address (e.g., client MAC address) is derived as 
shown in block 1956. For example, referring to the client device addressing table 
of Figure 34, given a layer 3 (e.g., IP) destination address 3410, the unique bit 
string (or context information) (e.g., the VPN-ID 3420 and 3430) and the layer 2 

25 destination address 3440 can be derived. (If, on the other hand, it is not assumed 
that the IP addresses are globally unique, a routing policy based on the layer 2 
and 3 addresses may be applied.) The packet is then forwarded to a logical 
interface of the (egress) access router, as shown in block 1958, where access 
control and rate limiting policies maybe applied based on the new unique bit 

30. string (or context information) (associated with the destination client device 
rather than the source client device) as shown in steps i960, 1962, 1964, 1966, 
1968, and 1970. More specifically, at the (egress) access router 812', an access 
control list (Recall, e.g.. Figure 25.) policy maybe applied as shown in block 
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1960, and the packet may be aUowed or denied based on the access control list 
policy as shown by decision block 1962. Recall from Figure 25 that the access 

control hst may use a portidn of the unique bit string (or context information) 
repladngthelayer 2 address information (See, e.g., column 2510 of Figure 25 
and columns 3225 and 3230 of Figure 32.) and/or a portion of the layer 3 address 
mformation (See, e.g., columns 2520 and 2530 of Figure 25 and columns 3205 
3210, 3215 and 3220 of Figure 32.) If the packet is denied' access, it may be 
forwarded to a security port «M2» as indicated by block 1964. If, on the other 
hand, the packet is allowed, as shown in block 1966 and decision block 1968 a 
rate hmiting policy maybe applied and enforced. (See, e.g., column 3250 of 
Figure 32.) If the customer (dient) device is exceeding the rate specified in its 
service level agreement, the packet(s) maybe forwarded to a service level 
agreement port "Ml" as shown by block 1970. If, on the other hand, the customer 
(chent) device is within the rate specified in its service level agreement, the 
packet may then be forwarded to a network facing interface of the a^gation 
device 1010' as shown by block 1972. 

As shown in blocks 1982 and 1984, the aggregation device ioio' 
may forward the packet based on the layer 2 (e.g., MAC) destmation address 
Recall that this address may have been derived from the client device addressing 
table of Figure 34. This address maybe used to detemiine a logical port or 
interface of the aggregation miit 1010'. (Recall, e.g., the address table of Figure 
30. 

Thus, the operations of an aggregation unit 1010' and an access 
router 812' on network bound and customer bound packets have been described. 

§4-5 CONCLUSIONS 

In view of the foregoing, it is clear that the aggregation unit of the 
present invention may advantageously permit access to an IP network with a 
robust and economical access technology such as Ethernet. Packets fix)m a lai^e 
number of physical Kne connections can be aggregated onto a smaller number of 
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high bandwidth links to an access router. Midticast groups are supported. The 
service provided to groups of customers may be easily copied for monitoring. 
The layer 2 (e.g., MAC) addressing scheme used by the present inventioh may 
permit the access router to control access to various services and locations, to 
5 facilitate virtual private netw'orks, and to support different quality of service 
levels. 

i ' . 



BNSOOCip: <WO ^02195eSA1J_> 



wo 02/19585 

WHAT IS CLAIMED IS: 



-51- 



PCT/USOl/24925 



15 



1. A method for provisioning services to packets sourced from a mmiber of client 
de-snces, each of the packets having at least a part of a layer 2 header replaced 
with a umque bit string, the method comprising: 

a) determining whether or not the packet is entitled to access a particular 
service based on at least a portion of at least one of (a) a layer 3 address of 
the packet, and (b) the unique bit string; and 

b) if it is determined that the packet is entitled to access the particular 
service, then routing the packet. 

2. -nie method of claun 1 wherein at least a portion of the unique bit string 
represents one of a number of logical interfaces. 

3. "I^e^iethodofclaimiwhereinatleastaportionoftheuniquebitstring 
corresponds to a VPN-OUI. 

4. The method of daun 1 wherein at least a portion of the unique bit string 
corresponds to a VPN-INDEX 

5. A method for providing various quality of service levels to packets sourced 

fromanumberofclientdevices,eachofthepacketshavingatleastapartofa 
layer 2 header replaced with a unique bit string, the method comprising: 

a) detennining a service level to which the packet is entitled based on at 
least a portion of at least one of (a) a layer 3 address of the packet, and (b) 
the unique bit string; and 

b) forwarding the packet to a queue associated v^dth the service level 
determined. 

30 6. The method of claim 5 wherein at least a portion of the unique bit string 
represents one of a number of logical interfaces. 
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7- The method of claim 5 wherein at least a portion of the unique bit string 
corresponds to a VPN-OUI. 

8. The method of claim 5 wherein at least a portion of the imique bit string 
corresponds to a VPN-INDEX. 

. 9- A method for monitoring packets sourced from a group of client devices 
defining a subset of client devices, each of the packets having at least a part of a 
layer 2 header replaced with a unique bit string, the method comprising: 

a) determining whether or not the packet belongs to the group of client 
devices based on at least a portion of at least one of (a) a layer 3 address of 
the packet, and (b) the imique bit string; and 

b) if it is determined that the packet does belong to the group of dient 
devices, then 

i) copying the packet to generate a duplicate packet, and 

ii) forwarding the duplicate packet to a monitoring facility. 

10. The method of daim 9 wherein at least a portion of the unique bit string 
represents one of a niomber of logical interfaces- 

11. The method of claim 9 wherein at least a portion of the lanique bit string 
corresponds to a VPN-OUI- 

12. The method of claim 9 wherein at least a portion of the unique bit string 
corresponds to a VPN-INDEX. 

13. An apparatus for provisioning services to packets sourced from a nimiber of 
client devices, each of the packets having at least a part of a layer 2 header 
replaced with a unique bit string, the apparatus comprising: 

a) an access control list; and 

b) an access controller, the access controller induding 

i) means for determining whether or not the packet is entitled td 
access a particular service based on 
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A) contents of the access control list, and 

B) at least a portion of at least one of (a) a layer 3 address of 
the packet, and (b) the unique bit string, and 

ii) means for routmg the packet if it is detenmned that the packet is 
entitled to access the particular service. 

14. An apparatus for providing various service levels to packets sourced from a 
number of client devices, each of the packets having at least a part of a layer 2 
header replaced AAdth a unique bit string, the apparatus comprising: 

a) a plurality of queues, each of the plurality of queues associated with a 
particular service level; - 

b) a service level list; and 

c) a service level controller, the service level contix)ller including 

i) means for determining a service level to which the packet is 
15 entitled based on 

A) contents of the service level list, and 

B) at least a portion of at least one of (a) a layer 3 address of 
the packet, and (b) the imique bit string, and 

ii) means for forwardmg the padcet to the one of the plurality of 
queues associated vwth the quaUty of service level determined. 



10 



20 



15. An apparatus for monitoring packets sourced from a group of chent devices 

defining a subset of client devices, each of the packets having at least a part of a 
layer 2 header replaced with a unique bit string, the apparatus comprising: 

25 a) a°»o°itoringportforacceptingpacketsofthegroupofdientdevicesto 

be monitored; 

b) means determining whether or not an accepted packet belongs to the 
group of client devices based on at least a portion of at least one of (a) a 
layer 3 address of the packet, and (b) the unique bit string; and 
30 c) means for 

i) copying the accepted packet to generate a dupHcate packet, and 

ii) forwarding the duplicate packet to the monitoring port. 
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if it is determined that the packet was sotirced by a client device belonging 
to the group of dient devices. 
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